[git-annex.git] /

[[!comment format=mdwn
 username="joey"
 subject="""comment 1"""
 date="2018-05-21T15:46:22Z"
 content="""
It wouldn't have actually copied 140 gb of files, unless you're using git-annex
on a filesystem that does not support hard links. If it used hard links,
it would not waste much space while running.

There may be edge cases where, if git-annex proxy did not copy/hard link
ignored files from the work tree to its temporary directory, the proxied
git command would not behave the same as an unproxed git command.

Let's see, such edge cases would have to involve a gitignored file that
is still somehow affected by the proxied git command.

The obvious case is, you have `.*` gitignored, and you run `git annex proxy
-- git add .foo --force` to add the ignored file. If git-annex didn't copy
`.foo`, that would fail, albeit in a fairly obvious way.

Another problem case: You have `.*` gitignored, and you have a local
file `.foo` which is not checked in. You run 
`git annex proxy -- git merge branch`, and the branch happens to add
`.foo` with different contents. The merge would normally fail, because
there are conflicting changes in the working tree. If proxy were
changed, the proxied merge would succeed. The local changes in this
case get lost. I've verified that this change causes data loss in this
situation.

So, the current behavior is the safe and right behavior; git-annex should
not lose data by default to optimise for an unusual edge case.

It could be an option, but it would have to be flagged as causing data
loss in some situations involving local modifications to gitignored files,
and causing proxied git behavior to differ from non-proxied git behavior
in other situations. I don't know if the potential benefit is worth the
foot-gun potential.

The code change is very simple if you want to play with it. In
Command/Proxy.hs find the Git.LsFiles line and change "True" to "False".
"""]]